﻿CRYPTEXT x64 – TECHNISCHE DOKUMENTATION
========================================
Stand: 0.11w fix1
Datum: 10. September 2026
Produktname: Cryptext x64
Interne Binärnamen: Cryptext64.exe / Cryptext64Shell.dll
Zielplattform: Windows x64, klassische native Win32-Anwendung
Assembler: Flat Assembler (FASM), getestet mit FASM 1.73.35

1. Zweck und Projektziel
------------------------
Cryptext x64 ist eine native 64-Bit-Dateiverschlüsselungsanwendung für Windows
und eine moderne Neuimplementierung der klassischen Windows-Shell-Erweiterung
Cryptext 3.4.

Das Projekt verfolgt vier Hauptziele:

1. Moderne authentifizierte Dateiverschlüsselung mit einem langfristig
   dokumentierten, versionsfähigen Dateiformat.
2. Kleine klassische Win32-Oberfläche ohne .NET, WebView oder große
   Laufzeitumgebungen.
3. Integration in den Windows Explorer über eine dünne x64-COM-Shell-Erweiterung.
4. Abwärtskompatibilität zum historischen Cryptext-3.x/3.4-Format ausschließlich
   zum Entschlüsseln alter Dateien.

Cryptext x64 verwendet weiterhin die historische Dateiendung:

    .$#!

Der sichtbare Produktname ist "Cryptext x64". Die internen Dateinamen
Cryptext64.exe und Cryptext64Shell.dll bleiben aus technischen und
Kompatibilitätsgründen bestehen.


2. Aktueller bestätigter Stand
------------------------------
0.11w fix1 ist der aktuell bestätigte stabile Projektstand.

Bestätigt funktionieren unter anderem:

- Verschlüsselung und Entschlüsselung im modernen CT64FILE-v1-Format.
- AES-256-GCM-Authentifizierung und PBKDF2-HMAC-SHA-256.
- Sichere Temp-Datei-/Verifikations-/Commit-Transaktion.
- Mehrfachauswahl und gemischte Batches.
- Kommandozeilenübergabe und Explorer-Shell-Erweiterung.
- Doppelklick auf .$#!-Dateien.
- Drag & Drop.
- "Always on Top".
- geschützte virtuelle Tastatur.
- lokaler Passworttresor mit PIN, DPAPI, PBKDF2, AES-GCM und A/B-Registry-Slots.
- Änderung des im Tresor gespeicherten langen Cryptext-Passworts.
- Deutsch/Englisch-Umschaltung.
- Cryptext-3.x/3.4-Legacy-Entschlüsselung.
- modaler About-Dialog mit 3-stufigem Dateisymbol-Easter-Egg.

Der Legacy-3.4-Pfad wurde praktisch mit echten durch Cryptext 3.4 erzeugten
Dateien getestet: 0 Byte, 1 Byte, 16 KiB, 16 KiB + 1 Byte, 4 MiB und
4 MiB + 1 Byte sowie weitere kleine Dateien; jeweils mit zwei verschiedenen
Passwörtern.

Der moderne CT64FILE-v1-Leser bestand außerdem Mutationstests mit manipulierten
Headern, Größen, Salts, Nonces, Ciphertexten, GCM-Tags sowie vertauschten,
duplizierten und entfernten Datenrecords.


3. Quelltextarchitektur
-----------------------
Wichtige Module:

    src\Cryptext64.asm
        Hauptprogramm, Fenster, Dialogsteuerung, zentrale UI-Logik,
        Meldungen, Ressourcen und Imports.

    src\fileformat.inc
        Eingefrorene Konstanten und Layoutdefinitionen für CT64FILE v1.

    src\fileformat_v1.asm
        Headeraufbau, Headerprüfung, Nonce-/AAD-Erzeugung und
        Dateiformat-Hilfsfunktionen.

    src\crypto_cng.asm
        Kryptografische Windows-CNG-Hilfsfunktionen.

    src\filecrypt.asm
        Moderne Datei-Verschlüsselung/-Entschlüsselung und sichere
        Dateitransaktionen.

    src\legacy34.asm
        Read-only-Kompatibilitätsleser für Cryptext 3.x/3.4.

    src\secure_input.asm
        geschützter Passwortpuffer und optionaler Session-Passwortcache.

    src\vkbd.asm
        virtuelle QWERTZ-Tastatur mit optionaler Randomisierung.

    src\vault.asm
        Tresorformat, DPAPI, KDF, AES-GCM, A/B-Slots und Tresorlogik.

    src\vault_ui.asm
        modale PIN-Dialoge und randomisiertes numerisches Bildschirm-Ziffernfeld.

    src\vault_change_ui.asm
        Änderung des im Tresor gespeicherten langen Cryptext-Passworts.

    src\progress.asm
        Fortschrittsfenster, Phasenanzeige, Disk-Sync und Telemetrie.

    src\cmdline.asm
        Kommandozeilenparser und Pfadübergabe.

    src\ui_extras.asm
        Drag & Drop, Systemmenü, Always on Top und Tresor-Menüeinträge.

    src\language.asm
        Deutsch/Englisch-Umschaltung und Sprachpräferenz.

    src\about.asm
        modaler About-Dialog und Dateisymbol-Easter-Egg.

    src\Cryptext64Shell.asm
        dünne Explorer-COM-Erweiterung; keine Passwörter und keine Kryptografie.


4. Build und Laufzeit
---------------------
Referenz-Buildumgebung:

    C:\fasm\FASM.EXE
    C:\fasm\INCLUDE

Build:

    build.bat

Das Projekt verwendet die normale FASM-Win64-Umgebung, insbesondere
win64a.inc. Ziel ist eine klassische native PE64-GUI-Anwendung.

Die Entwicklungs-/Testreferenz ist Windows 10 x64. Der Code ist für moderne
64-Bit-Windows-Systeme ausgelegt.


5. Passwortmodell und SecureInput
---------------------------------
Das echte lange Cryptext-Passwort wird nicht als Klartext in einem normalen
Windows-EDIT-Control gehalten.

SecureInput verwendet eine private 4096-Byte-Allokation:

    0x000..0x7FF   aktives Passwort
    0x800..0xFFF   optionales Session-Passwort

Die Allokation erfolgt mit VirtualAlloc. VirtualLock wird best-effort verwendet.
Ein Fehlschlag von VirtualLock darf die Kernfunktion nicht blockieren.

Das sichtbare Passwortfeld enthält nur Bullet-Zeichen. Der eigentliche
Passwortinhalt liegt im privaten SecureInput-Puffer.

Maximale Kapazität:

    CT_SECURE_INPUT_MAX_WCHARS = 512 UTF-16-Codeunits

Session-Modi:

    "Nicht im Speicher behalten"
        Session-Puffer wird nach der Operation verworfen.

    "Bis Cryptext beendet wird merken"
        Passwort wird in den separaten Session-Bereich kopiert und kann
        für weitere Operationen verwendet werden.

Beim Prozessende werden aktive und Session-Bereiche überschrieben.

CT64FILE v1 verwendet die EXAKTEN UTF-16LE-Codeunits des eingegebenen Passworts:

- kein abschließendes NUL im KDF-Input,
- keine Unicode-Normalisierung,
- keine Konvertierung in ANSI.

Dadurch können grundsätzlich auch Unicode-Zeichen und Zeichen oberhalb U+FFFF
(z. B. Emoji als UTF-16-Surrogatpaar) Bestandteil eines modernen
Cryptext-x64-Passworts sein.


6. Virtuelle Tastatur
---------------------
Die virtuelle Tastatur ist ein eigenes Win32-Fenster und schreibt direkt in
SecureInput.

Sicherheits-/Designregeln:

- kein SendInput,
- kein keybd_event,
- keine synthetischen WM_CHAR-/WM_KEYDOWN-Ereignisse,
- Button/Symbol-ID -> direkte interne SecureInput-Operation,
- WDA_EXCLUDEFROMCAPTURE best-effort,
- Multi-Monitor-Positionierung,
- sensible Beschriftungen werden bei bestimmten Mausinteraktionen verborgen,
- Randomisierung mit BCryptGenRandom,
- RNG-Fehler deaktiviert nicht die Eingabe; kanonisches QWERTZ bleibt nutzbar.

Die Tastatur startet in normaler QWERTZ-Anordnung. Die Randomisierung wird
bewusst vom Benutzer ausgelöst.

Eine zusätzliche versteckte Unicode-/Emoji-Palette wurde diskutiert, ist in
0.11w fix1 aber NOCH NICHT implementiert.


7. CT64FILE v1 – modernes Dateiformat
-------------------------------------
CT64FILE v1 ist eingefroren. Änderungen an diesem Layout dürfen nicht
stillschweigend unter derselben Versionsnummer erfolgen.

Kryptografie:

    KDF:        PBKDF2-HMAC-SHA-256
    Cipher:     AES-256-GCM
    Schlüssel:  256 Bit
    Salt:       16 Byte
    GCM-Tag:    16 Byte
    Writer-KDF: 600.000 Iterationen
    Writer-Chunkgröße: 4 MiB
    Reader-Maximum für PBKDF2: 10.000.000 Iterationen
    Reader-Chunkbereich: 64 KiB bis 64 MiB, Zweierpotenz

Windows CNG wird für die kryptografischen Primitive verwendet.


7.1 Fester Header, 72 Byte
--------------------------
Alle Integerfelder sind little-endian, sofern nicht anders angegeben.

Offset  Größe  Bedeutung
------  -----  --------------------------------------------------------------
0x00       8   Magic ASCII "CT64FILE"
0x08       2   FormatVersion = 1
0x0A       2   HeaderSize = 72
0x0C       4   Flags = 0
0x10       4   KdfId = 1 = PBKDF2-HMAC-SHA-256
0x14       4   CipherId = 1 = AES-256-GCM
0x18       4   PBKDF2-Iterationszahl
0x1C       4   Daten-Chunkgröße
0x20       8   ursprüngliche Klartextgröße
0x28       4   Metadata-Plaintextgröße = 48
0x2C       4   Reserved = 0
0x30      16   zufälliger Salt
0x40       8   zufälliger Nonce-Prefix


7.2 Verschlüsselte Metadaten, 48 Byte Klartext
-----------------------------------------------
Offset  Größe  Bedeutung
------  -----  --------------------------------------------------------------
0x00       4   MetadataVersion = 1
0x04       4   MetadataSize = 48
0x08       8   ursprüngliche Creation FILETIME
0x10       8   ursprüngliche LastWrite FILETIME
0x18       8   ursprüngliche LastAccess FILETIME
0x20       4   wiederherstellbare FILE_ATTRIBUTE_*-Bits
0x24       4   MetadataFlags = 0
0x28       8   Reserved = 0

Wiederherstellbare Grundattribute sind READONLY, HIDDEN, SYSTEM und ARCHIVE.


7.3 Records, Nonce und AAD
--------------------------
Record 0 ist der verschlüsselte Metadatenrecord.
Nutzdatenrecords beginnen bei Index 1.

Jeder Record ist eine unabhängige AES-GCM-Operation unter demselben pro Datei
abgeleiteten 256-Bit-Schlüssel.

12-Byte-Nonce:

    nonce[0..7]   = 8-Byte-Nonce-Prefix aus dem Header
    nonce[8..11]  = Recordindex als uint32 BIG-ENDIAN

80-Byte-AAD:

    AAD[0..71]    = exakte gespeicherte 72 Headerbytes
    AAD[72..75]   = Recordindex als uint32 little-endian
    AAD[76..79]   = Klartextlänge des Records als uint32 little-endian

Damit authentifiziert jeder Record den vollständigen festen Header sowie
seine eigene Position und Länge. Vertauschen oder Wiederverwenden eines
gültigen Records an einer anderen Position führt zu einem Authentifizierungsfehler.


7.4 On-Disk-Layout
------------------
Direkt nach dem Header:

    48 Byte Metadata-Ciphertext
    16 Byte Metadata-GCM-Tag

Danach je Nutzdatenchunk:

    Ciphertext in Klartextlänge
    16 Byte GCM-Tag

Es existieren keine separaten Recordheader.

Eine 0-Byte-Datei besitzt keinen Nutzdatenrecord, aber weiterhin den
authentifizierten Metadatenrecord.


7.5 Erwartete verschlüsselte Größe
----------------------------------
Mit:

    H = 72
    M = 48
    T = 16
    P = Klartextgröße
    C = Chunkgröße
    N = ceil(P / C), bei P=0 ist N=0

gilt:

    encrypted_size = H + M + T + P + N*T

Truncation und unerwartete zusätzliche Bytes am Dateiende werden abgelehnt.


7.6 Deterministischer Testvektor
--------------------------------
Passwort:
    Test0815$#!

PBKDF2-Iterationen:
    10000 (nur Testvektor)

Salt:
    000102030405060708090a0b0c0d0e0f

Nonce-Prefix:
    a0a1a2a3a4a5a6a7

Abgeleiteter Schlüssel:
    295851377f21a8a02f2f293f760f710ce4f724cb18a3c100ae22bca885b64ec8

Gesamtgröße:
    188 Byte

SHA-256:
    a402b22d38d109669d156520bae40890e530561e30fd3d044dea504262d59558


8. Sichere Dateitransaktion
---------------------------
Cryptext x64 verschlüsselt und entschlüsselt moderne Dateien niemals in-place.

8.1 Verschlüsselung
-------------------
Prinzip:

    Quelle read-only
        ->
    versteckte source.ext.$#!.temp mit CREATE_NEW
        ->
    vollständiges CT64FILE v1 schreiben
        ->
    FlushFileBuffers
        ->
    Temp schließen
        ->
    Temp read-only erneut öffnen
        ->
    Schlüssel aus gespeichertem Salt/Iterationswert neu ableiten
        ->
    alle GCM-Records authentifizieren/entschlüsseln
        ->
    byteweise gegen die weiterhin unangetastete Quelle vergleichen
        ->
    MoveFileExW(..., MOVEFILE_WRITE_THROUGH) auf source.ext.$#!
        ->
    Zeitstempel/Attribute finalisieren
        ->
    Quelle nur bei deaktiviertem "Originaldatei beibehalten" löschen

Eine existierende Zieldatei wird nicht still überschrieben.


8.2 Entschlüsselung
-------------------
Prinzip:

    verschlüsselte Quelle read-only
        ->
    versteckte Originalname.temp
        ->
    alle Records authentifiziert entschlüsseln
        ->
    FlushFileBuffers
        ->
    zweiter On-Disk-Verifikationslauf
        ->
    MoveFileExW WRITE_THROUGH auf Originalname
        ->
    authentifizierte Metadaten wiederherstellen
        ->
    .$#!-Quelle optional löschen

Beim Entschlüsseln wird nur die Endung .$#! entfernt. Der ursprüngliche
Dateiname wird in CT64FILE v1 nicht zusätzlich gespeichert.


8.3 Fehler- und Crashverhalten
------------------------------
- Quelle wird vor vollständigem Erfolg nicht gelöscht.
- Normale behandelte Fehler entfernen eine unvollständige Temp-Datei.
- Nach hartem Prozess-/OS-Absturz kann eine versteckte Temp-Datei zurückbleiben.
- ERROR_DISK_FULL wird behandelt.
- Es wird kein sicheres physisches Löschen auf SSD/HDD versprochen.
- Finalnamen werden nicht still überschrieben.


9. Disk-Sync und Fortschrittsanzeige
------------------------------------
Das Fortschrittsfenster arbeitet mit drei logischen Phasen:

    0..70 %   Schreiben / Ver- oder Entschlüsseln + Disk-Sync
    70..99 %  On-Disk-Verifikation
    99..100 % Finalisierung

Intern wird die Progressbar mit 0..1000 Einheiten betrieben:

    WRITE_END  = 700
    VERIFY_END = 990

FlushFileBuffers läuft in einem Hilfsthread. Der UI-Thread wartet in
50-ms-Schritten und pumpt Nachrichten. Dadurch bleibt die Oberfläche auch
bei langsamen Flush-Vorgängen ansprechbar.

"+ Disk-Sync" besitzt eine eigene visuelle Unterphase:
grau -> pulsierend während Flush -> schwarz.

Das Fortschrittsfenster besitzt bewusst kein Systemmenü, damit eine modale
Windows-Menüschleife die laufende Verarbeitung nicht anhält.


9.1 Telemetrie
--------------
Für große/langsame Operationen können rechts drei kompakte Zeilen erscheinen:

    Größe
    MiB/s
    ETA + Gesamtprozent

Ab 400 MiB wird die Größe sofort eingeblendet. Die Transferrate wird höchstens
einmal pro Sekunde aktualisiert und geglättet. Die ETA berücksichtigt in Phase 1
auch den noch kommenden vollständigen Verifikationsdurchlauf.


10. Mehrfachauswahl, Batch und Drag & Drop
------------------------------------------
Mehrere Dateien werden jeweils als eigene Transaktion verarbeitet.

Unterstützt:

- Explorer-/Dateidialog-Mehrfachauswahl,
- vollständige Pfade aus verschiedenen Verzeichnissen,
- gemischte Auswahl aus normalen und .$#!-Dateien,
- Drag & Drop einer oder mehrerer Dateien,
- AUTO-Modus: .$#! -> Entschlüsselung, andere Dateien -> Verschlüsselung.

Ordner werden über Drag & Drop derzeit nicht rekursiv verarbeitet.

Ein Fehler bei einer Datei rollt vorher erfolgreich abgeschlossene Dateien
nicht zurück. Bei Fehlern kann die Batch-Verarbeitung fortgesetzt werden.

Ein komplett erfolgreicher Batch zeigt keine zusätzliche Erfolgs-MessageBox.
Bei Fehler/Abbruch/Stop bleibt eine Zusammenfassung erhalten.

Die Zusammenfassung ist seit 0.11w versionsneutral:

    "Mehrfachauswahl abgeschlossen."


11. Kommandozeile
-----------------
Unterstützte Syntax:

    Cryptext64.exe [--auto|--encrypt|--decrypt]
                   [--keep-original|--delete-source]
                   "path1" ["path2" ...]

Beispiele:

    Cryptext64.exe --encrypt "D:\Test\a.bin" "E:\Daten\b.mkv"
    Cryptext64.exe --decrypt "D:\Test\a.bin.$#!"
    Cryptext64.exe --auto "D:\a.txt" "E:\secret.$#!"

"--" beendet die Optionsauswertung.

Kommandozeilenpfade werden zunächst in Cryptext-eigenen Speicher kopiert.
Die Kryptografie startet nicht allein durch den Kommandozeilenaufruf; der
normale Passwortdialog und die Bestätigung bleiben Teil des Workflows.


12. Explorer-Shell-Erweiterung
------------------------------
Datei:

    Cryptext64Shell.dll

Technik:

    native x64 COM In-Process Shell Extension
    IShellExtInit
    IContextMenu

CLSID:

    {2EDA86D0-E18E-43B4-9648-D3E4320C5FA7}

Die DLL ist absichtlich dünn:

- keine Passwörter,
- keine Dateikryptografie,
- keine Vault-Schlüssel,
- nur Auswahlpfade, Moduserkennung, Menü und Start der EXE.

Kontextmenü:

    normale Dateien     -> Verschlüsseln / Encrypt    -> --encrypt
    .$#!-Dateien        -> Entschlüsseln / Decrypt   -> --decrypt
    gemischte Auswahl   -> Cryptext                  -> --auto

Die Menüeinträge verwenden echte farbige 16/32/64-Pixel-Bitmaps.
Zuordnung:

    Verschlüsseln = geschlossenes Schloss mit Schlüssel
    Entschlüsseln = offenes Schloss

Der Dateityp lautet:

    ProgID: Cryptext64.EncryptedFile

Doppelklick:

    Cryptext64.exe --decrypt "%1"

Ein Doppelklick entschlüsselt nicht ohne Benutzerinteraktion; das Passwort
muss weiterhin eingegeben/bereitgestellt und die Operation bestätigt werden.


13. Per-User-Installation und Registry
--------------------------------------
Der aktuelle Testinstaller arbeitet pro Benutzer und benötigt keine
Administratorrechte.

Typischer Installationsort:

    %LOCALAPPDATA%\Cryptext64

Wichtige Registrierung:

    HKCU\Software\Classes\CLSID\
        {2EDA86D0-E18E-43B4-9648-D3E4320C5FA7}

    HKCU\Software\Classes\*\
        shellex\ContextMenuHandlers\Cryptext64

    HKCU\Software\Classes\.$#!

    HKCU\Software\Classes\Cryptext64.EncryptedFile

Beim Update wird eine bereits geladene Shell-DLL durch Abmelden der
Registrierung und erforderlichenfalls Explorer-Neustart freigegeben. Bei einer
Erstinstallation wird Explorer nicht unnötig neu gestartet.


14. Deutsch/Englisch-Umschaltung
--------------------------------
Sprachwert:

    HKCU\Software\Cryptext64
        Language   REG_DWORD

Werte:

    0 = Deutsch
    1 = Englisch

Fehlender/ungültiger Wert bedeutet Deutsch.

Die Umschaltung erfolgt über ein absichtlich unauffälliges 20x5-Pixel-Easter-Egg
oben rechts im Hauptfenster. Sichtbare Fläche und Hitbox sind beide exakt 20x5.

Die Explorer-Shell-Erweiterung liest dieselbe Registry-Präferenz dynamisch.
Für einen Sprachwechsel ist deshalb kein Explorer-Neustart vorgesehen.


15. Passworttresor
------------------
Der Tresor ist eine lokale Komfortfunktion. Er ändert das CT64FILE-v1-Format
nicht und ist NICHT erforderlich, um eine .$#!-Datei wiederherzustellen.

Wichtigste Regel:

    Die Datei wird weiterhin mit dem echten langen Cryptext-Passwort geschützt.
    Der Tresor speichert dieses Passwort nur lokal verschlüsselt und kann es
    später wieder in SecureInput laden.

Registry:

    HKCU\Software\Cryptext64\Vault

Produktive Slots:

    VaultA   REG_BINARY
    VaultB   REG_BINARY


15.1 Schlüsselhierarchie
------------------------
    PIN (4..6 Ziffern)
             +
    zufälliger Salt16
             +
    zufälliges DeviceSecret32
             |
             | DeviceSecret wird nur DPAPI-geschützt gespeichert
             v
    PBKDF2-HMAC-SHA-256
    600.000 Iterationen im aktuellen Writer
             |
             v
    256-Bit KEK
             |
             v
    AES-256-GCM entschlüsselt/wrappt
    zufälligen 256-Bit VaultKey
             |
             v
    AES-256-GCM schützt
    das echte lange Cryptext-Passwort

Das 32-Byte-DeviceSecret wird mit BCryptGenRandom erzeugt.
CryptProtectData/CryptUnprotectData werden ohne LOCAL_MACHINE-Bindung verwendet,
also an den aktuellen Windows-Benutzer gebunden.

Die Registry wird kryptografisch als öffentlich lesbarer/unvertrauenswürdiger
Speicher behandelt.


15.2 PIN
--------
Die PIN wird vom Benutzer selbst gewählt und muss 4 bis 6 Dezimalziffern
enthalten. Es ist keine separate feste Auswahl "4/5/6" nötig; jede Länge
innerhalb des Bereichs wird akzeptiert.

Die PIN wird nicht als echter Text in normalen EDIT-Controls gespeichert.
Die Felder zeigen nur Bullets; die Eingabe liegt in privaten Vault-Puffern.


15.3 Randomisiertes PIN-Ziffernfeld
-----------------------------------
Der PIN-Dialog kann ein eigenes Bildschirm-Ziffernfeld öffnen.

- Ziffern 0..9 werden bei jedem Öffnen neu gemischt.
- RNG: BCryptGenRandom.
- Klicks schreiben direkt in den internen PIN-Puffer.
- keine synthetischen Tastaturereignisse.
- Position bevorzugt rechts neben dem PIN-Dialog, dann links, unten, oben.
- Position wird an die Work Area des nächsten Monitors geklemmt.


15.4 Vault-Blob v1
------------------
Magic:

    "VLT1"

Fester Header:

    0x90 Byte

Maximale Blobgröße:

    4096 Byte

Aufbau:

    [0x90-Byte Header]
    [DPAPI(DeviceSecret32), variable Länge]
    [WrappedVaultKey, exakt 32 Byte]
    [EncryptedCryptextPassword, UTF-16LE, ohne NUL]

Headerfelder:

Offset  Größe  Bedeutung
------  -----  --------------------------------------------------------------
0x00       4   Magic "VLT1"
0x04       4   Version = 1
0x08       4   HeaderBytes = 0x90
0x0C       4   TotalBlobBytes
0x10       8   Generation
0x18       4   Flags = 0
0x1C       4   KDF-ID = 1
0x20       4   KDF-Iterationszahl
0x24       4   Cipher-ID = 1
0x28       4   Offset DPAPI-Blob
0x2C       4   Länge DPAPI-Blob
0x30       4   Offset WrappedVaultKey
0x34       4   Länge WrappedVaultKey = 32
0x38       4   Offset Password-Ciphertext
0x3C       4   Länge Password-Ciphertext
0x40      16   öffentlicher KDF-Salt
0x50      12   GCM-Nonce für VaultKey-Wrapping
0x5C      16   GCM-Tag für VaultKey-Wrapping
0x6C      12   GCM-Nonce für Passwortverschlüsselung
0x78      16   GCM-Tag für Passwortverschlüsselung
0x88       8   Reserved = 0


15.5 A/B-Slot-Regel
-------------------
VaultA und VaultB dienen der Absturz-/Stromausfallsicherheit, nicht als
zusätzlicher kryptografischer Faktor.

Eine Generation darf erst berücksichtigt werden, wenn der Slot vollständig:

1. strukturell geparst,
2. per DPAPI entsperrt,
3. mit PIN-PBKDF2 verarbeitet,
4. beim VaultKey-GCM authentifiziert,
5. beim Passwort-GCM authentifiziert

wurde.

Beim Update:

1. aktuellen gültigen Slot vollständig authentifizieren,
2. neue Generation = alt + 1 erzeugen,
3. neuen vollständigen Blob in den anderen Slot schreiben,
4. aus der Registry zurücklesen,
5. Bytevergleich und vollständige kryptografische Prüfung durchführen,
6. erst danach gilt die neue Generation als erfolgreich.

Der bisherige gültige Slot wird vorher nicht überschrieben.


15.6 "Passwort ändern..."
--------------------------
Der Hauptbutton "Passwort ändern..." ändert NICHT das Passwort bereits
verschlüsselter Dateien.

Er ändert ausschließlich das lange Cryptext-Passwort, das im lokalen Tresor
gespeichert ist.

Ablauf:

    Tresor-PIN authentifizieren
        ->
    neues langes Cryptext-Passwort + Wiederholung
        ->
    neue Vault-Generation in Gegen-Slot
        ->
    Readback + volle Authentifizierung
        ->
    neues Passwort wird aktiver SecureInput-Inhalt

Bereits verschlüsselte Dateien behalten das Passwort, mit dem sie ursprünglich
verschlüsselt wurden.

Der Dialog wird an die Monitor-Work-Area geklemmt. Die Bullet-Felder setzen
Caret/Selection nach Updates explizit ans Ende.


15.7 Noch nicht implementierte Tresor-Sperre
--------------------------------------------
Eine persistente Fehlversuchssperre wurde als nächster Härtungsschritt
diskutiert, ist in 0.11w fix1 aber noch NICHT implementiert.

Geplante Idee:

- nach mehreren falschen PINs zeitweise Sperre,
- exponentiell steigende Wartezeit,
- Sperrstatus persistent, damit ein einfacher Programmneustart nicht genügt.

Diese Sperre wäre primär gegen schnelles Durchprobieren über die lokale
Cryptext-Oberfläche gedacht, nicht als Ersatz für die kryptografische
DPAPI/PIN-Konstruktion.


16. Cryptext 3.x/3.4 Legacy-Unterstützung
-----------------------------------------
Der Legacy-Pfad ist DECRYPT-ONLY.

Cryptext x64 erzeugt niemals neue RC4/SHA-1-Dateien.

Erkennung:

    beginnt Datei mit "CT64FILE"
        -> moderner CT64FILE-v1-Leser
    sonst
        -> möglicher Legacy-3.x/3.4-Pfad


16.1 Legacy-Dateiaufbau
-----------------------
    [RC4-Ciphertext der Originaldatei]
    [12 Byte per-file Daten]
    [20 Byte Passwort-Prüfwert]

Gesamtgröße:

    original_size + 32

Die 12 Byte bestehen beim historischen Writer aus:

    8 Byte FILETIME
    4 Byte _rand()-Daten

Sie dienen der Schlüsseldiversifikation.


16.2 Legacy-Passwort und SHA-1
------------------------------
Das historische Passwortdialog-Verhalten ist ANSI.

Cryptext x64 konvertiert das aktuelle UTF-16-Passwort über die aktuelle
Windows-ANSI-Codepage und bildet:

    passwordHash = LegacySHA1(ANSI-Passwortbytes)

Passwortprüfung:

    check = LegacySHA1(passwordHash || ASCII "Cryptext")

RC4-Schlüssel:

    rc4Key = LegacySHA1(passwordHash || perFileData12)

Wichtige Kompatibilitätsbesonderheit:

Der originale Cryptext-SHA-1-Code speichert die fünf 32-Bit-Digest-Wörter in
nativer Little-Endian-Speicherreihenfolge. Windows CNG liefert dagegen die
übliche SHA-1-Bytefolge. Deshalb führt Legacy34_SHA1 nach BCryptFinishHash für
jedes der fünf DWORDs ein BSWAP durch.

Dieser Byteorder-Fix war entscheidend für die empirisch bestätigte
Cryptext-3.4-Kompatibilität.


16.3 Legacy-RC4
---------------
Der RC4-Key ist 20 Byte lang.

Die historische Dateiverarbeitung erfolgt in 0x4000-Byte-Blöcken:

    16 KiB

Der RC4-Zustand läuft kontinuierlich über Blockgrenzen hinweg.


16.4 Legacy-Integritätsgrenze
-----------------------------
Der 20-Byte-Trailer authentifiziert das Passwortmaterial, NICHT den gesamten
Ciphertext.

Das Legacy-Format besitzt daher keine moderne Whole-File-MAC bzw. AEAD-Garantie.
Eine beschädigte alte Datei kann nicht dieselbe Integritätssicherheit bieten wie
CT64FILE v1 mit AES-GCM.

Cryptext x64 übernimmt trotzdem die moderne sichere Dateitransaktion:
read-only Quelle, versteckte Temp-Datei, Flush, zweiter deterministischer
Decrypt-/Bytevergleich, WRITE_THROUGH-Rename und erst danach optionales Löschen
der alten .$#!-Datei.


17. About-Dialog und Dateisymbol-Easter-Egg
-------------------------------------------
Seit 0.11w ist "Info" eine echte modale Win32-Dialogbox
(DialogBoxIndirectParamW / DLGTEMPLATE), kein MessageBoxW.

Layout:

    Symbol links oben
    kurzer About-Text rechts
    flacher OK-Button

Deutsch:

    Entwickelt von
    NotCompatible (Basti) + GPT-5.6 Sol

    Erstellt mit FASM

Englisch:

    Developed by
    NotCompatible (Basti) + GPT-5.6 Sol

    Built with FASM


17.1 Easter Egg
---------------
Ein Klick auf das sichtbare About-Symbol schaltet zyklisch:

    Schlüssel -> AES v2 -> AES v3 -> Schlüssel -> ...

Es gibt bewusst keinen Tooltip/Hinweis.


17.2 Registry und Explorer-Icon
-------------------------------
Präferenz:

    HKCU\Software\Cryptext64
        FileIconVariant   REG_DWORD

Werte:

    0 = klassischer Cryptext-x64-Schlüssel
    1 = AES-Dateisymbol v2
    2 = AES-Dateisymbol v3

Dateityp:

    HKCU\Software\Classes\Cryptext64.EncryptedFile\DefaultIcon
        (Default) = <Cryptext64.exe>,0|1|2

Nach einem Wechsel ruft Cryptext:

    SHChangeNotify(SHCNE_ASSOCCHANGED, ...)

auf. Explorer wird dafür nicht beendet oder neu gestartet.

Die Icon-Ressourcengruppen im EXE sind:

    #1 = Variante 0
    #2 = Variante 1
    #3 = Variante 2

0.11w fix1 korrigierte STM_SETIMAGE auf 0x0172 und setzt den OK-Button auf
BS_FLAT.


18. Sicherheitsmodell
---------------------
Cryptext x64 schützt primär Dateien bei Speicherung, Transport und Verlust eines
nicht entsperrten Datenträgers.

Moderne Dateien:

- AES-256-GCM,
- authentifizierter Header/AAD,
- unabhängige authentifizierte Records,
- zufälliger Salt und Nonce-Prefix,
- PBKDF2,
- keine In-place-Verschlüsselung,
- vollständige On-Disk-Verifikation vor Commit.

Der lokale Tresor:

- Registry wird nicht als Geheimnis betrachtet,
- zufälliges 256-Bit-DeviceSecret,
- Current-User-DPAPI,
- PIN ist ein echter KDF-Faktor,
- zufälliger VaultKey,
- zwei AES-GCM-Schichten,
- A/B-Updates mit Readback.

Keine Schutzgarantie wird gegeben gegen:

- kompromittiertes aktives Windows,
- Administrator-/SYSTEM-/Kernel-Malware,
- privilegierte Debugger,
- Malware mit Zugriff auf den Cryptext-Prozessspeicher,
- Kameras bzw. externe Bildschirmbeobachtung,
- ein bereits entsperrtes System unter vollständiger Angreiferkontrolle.

VirtualLock und WDA_EXCLUDEFROMCAPTURE sind best-effort-Härtungen und keine
absolute Sicherheitsgrenze.


19. ADS / Zone.Identifier
-------------------------
CT64FILE v1 speichert keine NTFS Alternate Data Streams im Container.

Insbesondere Zone.Identifier / Mark-of-the-Web wird bewusst nicht
wiederhergestellt.

Andere ADS sind ebenfalls nicht Bestandteil von v1. Es wird daher aktuell keine
verlustfreie ADS-Garantie gegeben.

Eine spätere optionale ADS-Strategie wurde diskutiert, ist aber nicht Bestandteil
des eingefrorenen CT64FILE-v1-Formats.


20. Wiederherstellbarkeit und Formatstabilität
----------------------------------------------
Zentrale Designregel:

Eine .$#!-Datei darf nicht dauerhaft vom lokalen Tresor, der Registry, DPAPI,
der Shell-Erweiterung oder einer bestimmten Installation abhängig sein.

Für CT64FILE v1 reichen grundsätzlich:

    verschlüsselte Datei
    +
    echtes langes Cryptext-Passwort
    +
    kompatibler Reader

Der lokale Tresor ist nur Komfort.

Für die Zukunft ist ein minimales portables CryptextDecrypt.exe vorgesehen:

- nur Entschlüsselung,
- keine Shell-Abhängigkeit,
- keine Vault-/Registry-/DPAPI-Pflicht,
- moderne veröffentlichte CT64FILE-Versionen lesen,
- Cryptext 3.x/3.4 decrypt-only unterstützen.

Dieses Recovery-Programm ist in 0.11w fix1 noch nicht implementiert.


21. Aktuell bekannte noch offene Punkte
---------------------------------------
Nicht bzw. noch nicht vollständig umgesetzt:

- persistente PIN-Fehlversuchssperre für den Tresor,
- eigenständiges CryptextDecrypt.exe-Recoveryprogramm,
- Free-Space-Precheck vor großen Transaktionen,
- sicher definierter alternativer %TEMP%-Staging-Pfad bei Platzmangel,
- vollständige Vault-Verwaltung wie PIN ändern / Vault bewusst löschen/resetten,
- explizite Funktion "zwischengespeicherte Passwörter löschen",
- rekursive Ordnerverarbeitung aus der Shell,
- verlustfreie ADS-Unterstützung,
- optionale versteckte Unicode-/Emoji-Palette der virtuellen Tastatur,
- finaler Installer/Uninstaller-Feinschliff und weitere DPI-Politur.

Diese Punkte dürfen nicht als bereits vorhandene Funktionen dokumentiert werden.


22. Wichtige Invarianten für weitere Entwicklung
-------------------------------------------------
1. CT64FILE v1 bleibt unverändert.
2. Formatänderungen benötigen eine neue Formatversion.
3. Neue Dateien werden niemals im alten RC4/SHA-1-Format erzeugt.
4. Legacy-Code bleibt decrypt-only.
5. Die Explorer-DLL bleibt frei von Passwörtern und Kryptografie.
6. Die Quelle wird vor vollständigem Erfolg nicht gelöscht.
7. Keine stillen Zielüberschreibungen.
8. Vault/DPAPI ist keine Voraussetzung zum Wiederherstellen moderner Dateien.
9. Optionale UI-/Schutzfunktionen dürfen den Datei-Kernpfad nicht unbrauchbar machen.
10. Kryptografische Primitive werden über Windows CNG/DPAPI genutzt; kein eigener
    AES-/GCM-/RNG-Code.
11. Passwortbytes für CT64FILE v1 bleiben exakte UTF-16LE-Codeunits ohne
    Unicode-Normalisierung.
12. Bei Vault-A/B-Auswahl darf eine Generation erst nach vollständiger
    kryptografischer Authentifizierung berücksichtigt werden.


23. Testempfehlungen für Regressionen
-------------------------------------
Nach Änderungen an sicherheitsrelevanten Modulen mindestens:

Modern CT64FILE v1:
- 0 Byte
- 1 Byte
- 4 MiB
- 4 MiB + 1 Byte
- mehrere Records, z. B. 8 MiB + 1 Byte
- falsches Passwort
- Header-/Ciphertext-/Tag-Manipulation
- Truncation und trailing bytes
- Quellbehalten / Quelllöschen
- Batch und Abbruch
- langsamer Disk-Sync

Legacy:
- 0 Byte
- 1 Byte
- 16 KiB
- 16 KiB + 1 Byte
- 4 MiB
- 4 MiB + 1 Byte
- mindestens zwei verschiedene ASCII-Passwörter
- falsches Passwort

Vault:
- Setup 4/5/6-stellige PIN
- falsche PIN
- Neustart und Unlock
- A/B-Readback
- gespeichertes langes Passwort ändern
- bereits vorhandene Datei weiterhin nur mit ihrem alten Passwort öffnen

Shell/UI:
- Encrypt/Decrypt-Kontextmenü
- Doppelklick
- Drag & Drop
- DE/EN
- About-Icon 0 -> 1 -> 2 -> 0
- Explorer-Icon-Refresh
- Flat-Buttons und Multi-Monitor-Clamp


24. Schlussbemerkung
--------------------
Cryptext x64 0.11w fix1 kombiniert einen modernen, authentifizierten und
transaktionssicheren CT64FILE-v1-Pfad mit einem bewusst getrennten,
decrypt-only Legacy-Reader für historische Cryptext-3.x/3.4-Dateien.

Der wichtigste Kompatibilitätsgrundsatz lautet:

    Neue Sicherheit für neue Dateien,
    aber lesbarer Zugriff auf alte Cryptext-Dateien.

Der wichtigste Recovery-Grundsatz lautet:

    Das echte lange Passwort und die .$#!-Datei müssen genügen;
    der lokale Komfort-Tresor darf niemals zur dauerhaften
    Wiederherstellungsvoraussetzung werden.
